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REMARKS 

In view of the foregoing amendments and following remarks responsive to the 
Office Action dated July 5, 2005, Applicant respectfully requests favorable 
reconsideration of this application. 

Claims are 1-21 were pending in this application. Applicant has entered no 
amendments to the claims. Accordingly, claims 1-21 remain pending in this application. 

In reviewing this application for purposes of responding to the Office Action, 
Applicant noted several clerical and/or typographical errors in the specification. 
Accordingly, Applicant has herein corrected those errors. The corrections are self- 
explanatory. 

The Present Invention 

The present invention is a method and apparatus that can be implemented as a 
software program (or a software module of a larger software program) for determining 
tax location information with respect to assets such as capitalized fixed assets. In 
accordance with the invention, the software of the present invention is integrated into a 
larger software system that includes software modules (herein termed controllers) 
within which transactions concerning assets are recorded. The inventive software is 
integrated with the controller software modules so that, when a transaction (e.g., a 
transfer, capitalization or update) concerning a particular asset is recorded in a 
controller software module, that controller software module calls the tax location finder 
module of the present invention and provides the tax location finder module with the 
transaction record. The inventive tax location finder module then runs through a 
hierarchical sequence of checks or queries using the information assigned to the asset. 
In each query, the tax location finder module will check to determine if the data 
assigned to the asset meets a set of criteria that helps indicate a particular routine (or 
audit) that will probably be able to derive the location of the asset (for tax, insurance or 
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other reporting purposes). Such criteria typically might comprise conditions that 
indicate the type of the asset (e.g., manufacturing equipment vs. real estate vs. 
furniture) and/or the nature of the asset's use (e.g., internal vs. customer site vs. loaner 
vs. vendor site equipment) and/or the building, employee or cost center to which the 
asset is assigned. 

If the data associated with the asset meets the set of criteria for a particular 
audit, then that audit routine will be called. If the asset does not meet the query criteria 
for an audit, then it will continue on to the next sequential query until it encounters a 
query whose criteria it meets. When the asset meets the set of criteria for a particular 
audit, the audit is called. Each audit is customized to the asset or transaction qualities 
that caused it to meet the criteria for calling that audit so that the logic in that routine will 
likely be able to derive a location for that asset. In a preferred embodiment of the 
invention, the queries at the front of the routine are very specific and they become more 
general as one goes down the hierarchy. 

The called audit checks through the data available in the transaction record 
and/or one or more tables or databases with asset information that are maintained by 
the corporation and to which the tax location finder module has access to derive the 
location of the asset. 

In a preferred embodiment of the invention, once an audit is called, there are two 
possible results. First, if the audit routine discovers sufficient data to derive a tax 
jurisdiction code, then the derived tax jurisdiction code is passed back to calling 
controller. The audit logic may also pass back additional location related information, 
such as the building number, work location and a location type that indicates the source 
table from which the tax jurisdiction was obtained. The second possibility is that the 
audit could not successfully derive a tax jurisdiction from the available information due, 
for example, to invalid data in the transaction record or on a table called in the routine. 
In this case, the transaction record is sent to an error correction facility where they are 
manually researched and corrected. 
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In some embodiments, a third result may be allowed. For instance, depending 
on the particular audit, there may be circumstances where a transaction record causes 
an audit to be invoked and that audit cannot derive a location for the asset, but the P 
condition that precipitated the failure to derive a tax location is not necessarily an error 
that needs correction. Rather, the failure to derive a location may be the result of 
selecting that audit incorrectly, but a subsequent audit in the hierarchy may still be able 
to successfully derive a location, if given the opportunity. Accordingly, one or more 
audit routines may be designed to return the record transaction back into the hierarchy 
of queries if the audit fails for certain reasons. 



Claim Rejections 

The Office rejected all claims, claims 1-21, under 35 USC 102(e) as anticipated 
by Elston. Particularly, the Office asserted that: 



Elston shows, in figure 2, a remote ordering system for mobile commerce. All 
transactions are routed through a Tax Engine 58 (page 20, external software). 
The Tax Engine 58 computes the sales tax applicable (detecting when a 
capitalized fixed asset is involved in a transaction) to the order. It should be 
understood that sales tax can be interpreted in a very broad sense to include 
state, county and local taxes, Value Added Tax (VAT), Goods and Services Tax 
(GST),and surtaxes, etc. (all categories with certain criterion, including 
jurisdiction location). The tax engine inquiries (plurality of queries) the Store 
information directory 36 (store and customer locations included) for the tax codes 
(which include tax rates and rules for applying the tax rate) applicable to the 
items in the order. The rules and parameters used for determining which tax rate 
applies and the tax amounts are found in the store information directory Tax 
computation information, including the tax codes applied, is passed to the 
payment engine 12 for logging and reporting. Error flags and alarms are used if 
any part of the delivery process does not work. As far as hierarchy, if the asset 
does not meet the initial crate. For a particular tax, further queries would not be 
done. 



Applicant's Response 

Applicant respectfully traverses. Elston discloses a remote ordering system 
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particularly suited to mobile customers placing remote orders with any one of a group of 

affiliated merchants for pick up by the customer at a specific merchant location. The 

system includes a database or store information directory that contains information 

characterizing order-processing features for each location. The information is preferably 

organized according to a schema corresponding to the organizational structure of the 

group of merchants. The information may include order fulfillment capability, menus, 

prices, payment features, taxes, security protocols and system administration privileges 

specific to each merchant location or sub-groups of merchant locations. The system 

allows the remote ordering system to effectively pre-clear, pre-process and pre-pay 

remote orders and to effect post-sale settlement and reporting according to guidelines 

applicable to each specific location in the merchant group, leaving the specific location 

to complete only the actual order fulfillment. 

Elston is a very long reference of which only a small portion, namely, the Tax 

Engine 58 described on page 20, paragraphs 361 and 362, is referred to by the Office. 

However, what is described with respect to the Tax Engine in Elston is very different 

than the present invention as claimed. Specifically, the present invention is directed 

toward a way to determine the location of an asset for tax purposes. Elston, on the 

other hand, simply needs to determine the specific taxes to charge a customer that is 

purchasing a product. Paragraphs 361-362 of Elston state: 

The tax engine 58 computes the sales taxes applicable to the order. It should be 
understood that sales tax can be interpreted in a very broad sense to include state, county 
and local taxes, Value Added Tax (VAT), Goods and Services Tax (GST), surtaxes, etc. 
The tax engine queries the Store information directory 36 for the tax codes (which 
include tax rates and rules for applying the tax rate) applicable to the items in the order. 
The rules and parameters used for determining which tax rate applies and the tax amount 
are found in the store information directory Tax computation information, including the 
tax codes applied, is passed to the payment engine 12 for logging and reporting. 

When promotional value is used for some or all of the payment, tax is computed for the 
balance of the cost of the order on an item (or category) specific basis. Alternatively, tax 
can be computed for the entire value of the order and then tax credits computed for the 
item (or category) specific promotional value. In some jurisdictions and for some types of 
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items, it may be required to compute the tax on the item ordered based on the listed price, 
regardless of the promotional value applied. 

Referring to the second sentence of the first paragraph quoted above, it is quite 
clear that the only thing that Elston's Tax Engine does is calculate taxes based on tax 
codes that are stored in the Store information directory in association with the particular 
products. Thus, Elston does not disclose a technique for determining the tax location of 
an asset based on queries for information relevant to its tax location. Rather, that 
information has already been determined and stored in the Store information directory. 
In fact, to say that the tax location is stored in the Store information directory is itself too 
strong of a statement. All that is stored is a tax code. There is nothing suggesting that 
the tax code actually discloses the tax location. Rather, it seems implicit in Elston's 
description that it does not disclose the tax location. It probably discloses only the local 
tax rate, which is based on tax location, but hardly can be deemed to even disclose the 
tax location (since many places have the same local tax rates). 

There simply are fields in the Store information directory 36 (i.e., the "tax codes") 
that tell what the taxes are for that product. Clearly, some of those taxes are based on 
the tax location of the product, but the Tax Engine described by Elston does not 
determine the tax location through a series of queries. Rather, it simply reads the 
appropriate tax code field in the Store information directory. All the Tax Engine seems 
to retrieve from the directory 36 is the tax code, which presumably gives the local tax 
rate for that type of product so that the payment engine can calculate the local tax on 
the product by multiplying the local tax rate by the cost of the product. 

Thus, referring to the language of the independent claim 1, for instance, Elston 
does not meet the limitations of "running data for said asset through a plurality of 
queries, each query designed to determine if said asset meets a set of criteria indicative 
of a category of how a location of said asset may be determined" (step (2)) or "if, in step 
(2), said asset meets said set of criteria corresponding to one of said queries, running 
data corresponding to said asset through an audit customized to said corresponding 
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category to determine a location of said asset" (step (3)). It cannot reasonably be said 
that looking up a tax code in a directory meets these limitations concerning running the 
data for that asset through a plurality of queries indicative of a category of how a 
location of said asset may be determined. 

Note that claim step (2) does not recite that these queries are trying to find the 
location of the asset. Rather step (2) concerns trying to find data indicative of a 
category of asset to which that asset corresponds from which one might be able to find 
its tax location . This is followed up by step (3), in which the software tries to determine 
the tax location of the asset only if one of the queries in step (2) was successful. 

There is nothing in Elston that even remotely resembles these claim recitations. 

Furthermore, steps (4)-(6) of claim 1 recite: 

(4) if, in step (3) a location is determined, assigning said determined 
location to said asset for tax and/or insurance reporting purposes; 

(5) if, in step (3), a location is not determined issuing an error notification; 

and 

(6) if, in step (2), if said data for said asset does not meet said criteria of 
any of queries, issuing an error notification. 

Elston could not possibly disclose technology corresponding to these recitations- 
because all Elston does is look up a code in a directory that discloses the local tax rate. 
In Elston's Tax Engine, there is no step like step (4) of assigning a tax location for the 
asset. The tax location is already assigned. In Elston, there is nothing to indicate that 
the Tax Engine even knows the tax location of the asset. It only knows the tax code 
that it found in the Store information directory. To any extent that the Office is trying to 
assert that the tax code in the Store information directory is the tax location of the 
product, it still cannot be reasonably said that the Tax Engine is assigning a tax location 
to the product. The product already has a tax location assigned to it via the tax code 
stored in the Store information directory. 

With respect to steps (5) and (6), it seems that the Office is asserting that these 
are disclosed in Elston because "error flags and alarms are used in any part of the 
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delivery process does not work" (Office Action, page 3). The Office appears to be 

referring to paragraph 146 of Elston, which contains essentially the only substantive 

discussion of error flags in the entire reference. It states: 

During the normal order delivery process a number of check steps are taken to trap and 
process errors. At each of these steps, if a failure occurs the order delivery system 40 sets 
error flags (252) and initiates an alternative order delivery process (shown in FIG. 5C) if 
one is available. The error flags are used to indicate to the order delivery system that the 
remote order service is not available via that delivery path. Further, setting the error flag 
sets alarms for operations staff to take corrective action. Once the problem has been 
corrected, the error flag is reset. 

As can be seen, this paragraph discloses an error flag in connection with steps 
having nothing to do with the Tax Engine or tax location of the product. Therefore, it 
does not meet the limitations recited in steps (5) and (6). 

Accordingly, Elston clearly does not anticipate claim 1 or any of its dependent 
claims 2-7. 

Nevertheless, the dependent claims add even further distinguishing recitations. 
For instance, claim 2 recites "in step (2), each of said sets of criteria comprises at least 
one criterion to which said data for said asset must match". It is not seen how the act of 
looking up the local tax rate in a directory could possibly be deemed to meet this 
limitation. 

Dependent claim 3 recites "in step (2), said data for said asset is run through 
said plurality of queries hierarchically, wherein, when said asset meets said set of 
criteria of a particular query, said asset data is not run through any queries ordered 
lower in said hierarchy". There is nothing in Elston remotely resembling this recitation. 
Elston looks up a field in a directory that tells it the local tax rate. There is no hierarchy 
of queries. 

With respect to this limitation in claim 3, the Office argued that "As far as 
hierarchy, if the asset does not meet the initial criteria for a particular tax, further 
queries would not be done". Applicant, of course, does not fully comprehend the 
meaning of this statement since Elston does not has a plurality of queries in the first 
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instance. However, it does disclose a misreading of claim 3 by the Office. Particularly, 
claim 3 recites that no further, lower-ordered queries are made if the asset meets the 
criteria for any higher-ordered query in the hierarchy. However, the rejection asserts 
that Elston teaches the opposite, i.e., "if the asset does not meet the initial criteria for a 
particular tax, further queries would not be done". Of course, Applicant contends that 
Elston is so inapposite that it teaches neither. However, in any event, to whatever 
extend the Office believes that Elston contains such a teaching, it is exactly the 
opposite of what is claimed. 

Dependent claims 5-7 also further distinguish over Elston. Each of these claims 
discusses a particular feature pertaining to the criteria used to determine which 
category an asset belongs to in order to determine which audit to run so as to 
determine its tax location. Since Elston does not have any such criteria since he has no 
step similar to step (2), it cannot possibly disclose these specific features. 

Independent claim 8 is quite similar to claim 1 and distinguishes over Elston for 
at least all of the same reasons set forth above in connection with claim 1 . 

Dependent claims 9-18 are patentable for at least the same reasons since they 
depend from claim 8. However, even furthermore, dependent claims 10, 11, 13, 14, 
and 15 generally correspond in substance to dependent claims 2, 3, 5, 6, and 7 
discussed above. Therefore, they even further distinguish over Elston for at least all of 
the same reasons already discussed above with respect to dependent claims 2, 3, 5, 6, 
and 7. 

Finally, the third claim set, i.e., independent claim 19 and dependent claims 20 
and 21 generally correspond in substance to claims 1 , 2, and 3. Therefore, they 
distinguish over Elston for at least all of the same reasons as claim 1 , 2, and 3, 
respectively. 

Conclusion 

In view of the foregoing amendments and remarks, Applicant asserts that the 
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pending claims are in condition for allowance and respectfully request that the Office 
issue a Notice of Allowance at the earliest possible date. The Office is invited to 
contact Applicant's undersigned counsel by telephone call in order to further the 
prosecution of this case in any way. 



Respectfully submitted, 




Theodore Naccarella, Reg. No. 33,023 
Synnestvedt & Lechner LLP 
2600 Aramark Tower 
1101 Market Street 
Philadelphia, PA 19107-2950 



Tele: (215)923-4466 
Fax: (215)923-2189 
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